Test Results

  118 files  ±0    118 suites  ±0   15m 54s ⏱️ - 1m 1s
4 650 tests ±0  4 633 ✅ ±0  17 💤 ±0  0 ❌ ±0 
  330 runs  ±0    326 ✅ ±0   4 💤 ±0  0 ❌ ±0 

Results for commit 386aef6. ± Comparison against base commit 910f5cd.

♻️ This comment has been updated with latest results.

Does anybody have an opinion on this?

@HeikoKlare What do you think of this one?

Sounds reasonable to me. I fully agree with:

I think that's the more natural way to resolve this issue and has the advantage that we only temporarily have to add filters to suppress the error that a method/field became non-api.

It will allow us to get rid of most of the API filter for the Windows fragments, which would be really great. And I don't see any risk either, because if someone unexpectedly relies on those methods being API, they will still exist and will still be referencable.

The current failures seem to be caused by the temporary filters for the API removals missing in the aarch64 fragment. @HannesWell do you want to add them so that we may even merge this for the upcoming release and can get rid of all the filters already in December?

This is an old PR.

The current failures seem to be caused by the temporary filters for the API removals missing in the aarch64 fragment. @HannesWell do you want to add them so that we may even merge this for the upcoming release and can get rid of all the filters already in December?

Just done it. And yes, I assume we could then remove them soon.